Providing demand response

ABSTRACT

Devices, methods, and systems for providing demand response are described herein. One device includes instructions executable to receive an indication of a demand response event, determine, based on a configuration made using a user interface, an action to be taken by a load of a facility in response to the demand response event, communicate the determined action to a controller associated with the load, and monitor a status of the action as the action is taken.

The present application is a continuation of U.S. patent applicationSer. No. 15/254,856, filed Sep. 1, 2016, entitled, “Providing DemandResponse” which is hereby incorporated by reference.

TECHNICAL FIELD

The present disclosure relates to devices, methods, and systems forproviding demand response.

BACKGROUND

Demand response can include voluntary changes in electricity usage of anelectric utility customer (e.g., facility) to better match the demandfor power with the supply. Demand response can allow for the reductionof load on electrical grids based on signals that are sent tofacilities. For example, a demand response request sent to a facility byan electricity supplier or other grid management entity can result insome number of loads in that facility being shut down and/or running atreduced capacity.

During demand response when equipment is shutdown or running at reducedcapacity, it can be possible to adversely affect conditions in thefacility. In addition, a demand response event can have differentintensity levels. Previous approaches to demand response may not providesufficient flexibility to accommodate different event intensity levelswhile maintaining for adequate control of facility equipment withoutimpact to conditions. For instance, facility loads may be set to takeone action only during demand response despite differing event severitylevels. Additionally, there may be multiple settings for demand responselocated in different locations in user interfaces resulting in anover-complicated workflow. Previous user interfaces for demand responseconfiguration in a facility may not provide a way for building managersto quickly configure a large number of loads while also being able tocustomize a demand response strategy. Further, previous interfaces maynot provide a summary of the demand response strategy that has beenconfigured for a given facility.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a system for providing demand response in accordancewith one or more embodiments of the present disclosure.

FIG. 2 illustrates a user interface associated with monitoring demandcontrol in accordance with one or more embodiments of the presentdisclosure.

FIG. 3 illustrates an interface associated with configuring loads inaccordance with one or more embodiments of the present disclosure.

FIG. 4 illustrates an interface associated with scheduling limitingevents in accordance with one or more embodiments of the presentdisclosure.

FIG. 5 illustrates an interface associated with modifying peak targetsin accordance with one or more embodiments of the present disclosure.

FIG. 6 illustrates an interface associated with modifying demand controlsettings in accordance with one or more embodiments of the presentdisclosure.

DETAILED DESCRIPTION

Devices, methods, and systems for providing demand response aredescribed herein. For example, one or more embodiments include a devicehaving instructions stored thereon executable to receive an indicationof a demand response event, determine, based on a configuration madeusing a user interface, an action to be taken by a load of a facility inresponse to the demand response event, communicate the determined actionto a controller associated with the load, and monitor a status of theaction as the action is taken.

Demand response, as referred to herein, can include voluntary changes inelectricity usage by an electric utility customer (e.g., facility) inresponse to a request by an electricity supplier or other gridmanagement entity; this request typically occurs when there is heavydemand for electricity on the electrical grid, and is intended toprevent temporary electricity shortfalls. A demand response request isreferred to as a demand response event, and can be sent to a customervia email or text message, or via an automated signal, wherein thelatter may be referred to as automated demand response (ADR). When ademand response event is sent to a customer, it is the customer'sresponsibility to take actions to reduce electrical usage for someperiod of time specified in the event message—this typically means thatsome number of electrical loads in one or more customer facilities areshut down and/or run at reduced capacity.

During demand response when equipment is shutdown or running at reducedcapacity, it can be possible to adversely affect conditions in thefacility. In addition, a demand response event can have differentintensity levels. Previous approaches to demand response may not providesufficient flexibility to accommodate different event intensity levelswhile maintaining for adequate control of facility equipment withoutimpact to conditions. For instance, facility loads may be set to takeone action only during demand response despite differing event severitylevels. Additionally, there may be multiple settings for demand responselocated in different locations in user interfaces resulting in anover-complicated workflow. Previous user interfaces for demand responseconfiguration in a facility may not provide a way for building managersto quickly configure a large number of loads while also being able tocustomize a demand response strategy. Further, previous interfaces maynot provide a summary of the demand response strategy that has beenconfigured for a given facility.

Demand response (e.g., demand control) in accordance with one or moreembodiments of the present disclosure can provide flexibility incontrolling a facility. For instance, loads may be set to take differentactions according to differing event seventies. Building managers usingembodiments here can configure a large number of loads, visualize theirdemand response strategy, and customize that strategy, all at a glance.

Embodiments of the present disclosure can include a comprehensive ADRsystem provided to a user that allows for easier configuration comparedto previous approaches. In some embodiments, for instance, ADR eventsfrom a demand response automation server (DRAS) can be parsed (e.g., byan executive control module) and passed along to a demand controlservice component (sometimes referred to herein simply as “computingdevice.”). The computing device can take information about operationmode (e.g., event severity), target (e.g., required electricityreduction) , target type (e.g., electricity reduction or firm kWthreshold), etc. to determine what actions the facility (e.g., devicesand/or loads of the facility) should take. Those determined actions canbe passed to equipment controllers, which can execute them. Embodimentsherein include a user interface that allows monitoring of the wholefacility, as well as quick configuration of loads and/or settings.

As discussed further below, the user interface can include monitoringscreens that show information about all loads of the facility,configuration screens (e.g., tabs) that allow all facility settings tobe configured at once, and load configuration screens (e.g., pop-ups)that allow bulk configuration of loads.

In addition, embodiments here can allow the selection of differentstrategies including, for example, load rolling and load staging.Different strategies can be assigned to each of the different operationmodes for events. Moreover, embodiments herein can utilize virtual shedgroups instead of fixed registers, wherein loads can be assigned a groupnumber. Virtual shed groups can allow for a larger number ofparticipating loads compared to previous approaches.

A demand limiting schedule in accordance with embodiments herein canallow for more scheduling flexibility in that each alternate scheduleand/or special event can have a separate set of limiting targets forgreater control. A demand settings component can provide a level ofabstraction between the service (e.g., the computing device) and eachload. As a result, new load types and/or load strategies can be addedwithout modifying the service, and third party loads can be used byconfiguring a strategy (e.g., in wiresheet) and using the demandsettings component's shed output to drive logic.

As referred to herein, an event can include a signal and/or a request toreduce load. An event can be a signal in response to which a number ofloads are shut down or run at reduced capacity. In some embodiments,events can be sent (e.g., issued) from a utility. In some embodiments,events can be scheduled (e.g., manually scheduled) by facilitiesthemselves. It is noted that where the singular “facility” is usedherein, such reference can refer to any number of structures, buildings,plants, refineries, sites, etc.

Load, as referred to herein, includes electricity use by one or moredevices and/or systems. For example, loads can refer to units and/orsystems associated with heating, ventilation, and air conditioning(HVAC), refrigeration, lighting, and/or industrial equipment, amongothers.

In the following detailed description, reference is made to theaccompanying drawings that form a part hereof. The drawings show by wayof illustration how one or more embodiments of the disclosure may bepracticed.

These embodiments are described in sufficient detail to enable those ofordinary skill in the art to practice one or more embodiments of thisdisclosure. It is to be understood that other embodiments may beutilized and that process changes may be made without departing from thescope of the present disclosure.

As will be appreciated, elements shown in the various embodiments hereincan be added, exchanged, combined, and/or eliminated so as to provide anumber of additional embodiments of the present disclosure. Theproportion and the relative scale of the elements provided in thefigures are intended to illustrate the embodiments of the presentdisclosure, and should not be taken in a limiting sense.

The figures herein follow a numbering convention in which the firstdigit or digits correspond to the drawing figure number and theremaining digits identify an element or component in the drawing.Similar elements or components between different figures may beidentified by the use of similar digits.

As used herein, “a” or “a number of” something can refer to one or moresuch things. For example, “a number of loads” can refer to one or moreloads.

FIG. 1 illustrates a system 100 for providing demand response inaccordance with one or more embodiments of the present disclosure. Asshown in FIG. 1, the system 100 can include a demand control service(DCS) component 102. The DCS 102 can be a computing device, forinstance.

DCS 102 can be, for example, a laptop computer, a desktop computer, or amobile device (e.g., a mobile phone, a personal digital assistant,etc.), among other types of computing devices.

As shown in FIG. 1, DCS 102 includes a memory 103 and a processor 105coupled to memory 103. Memory 103 can be any type of storage medium thatcan be accessed by processor 105 to perform various examples of thepresent disclosure. For example, memory 103 can be a non-transitorycomputer readable medium having computer readable instructions (e.g.,computer program instructions) stored thereon that are executable byprocessor 105 to provide demand response in accordance with one or moreembodiments of the present disclosure.

Memory 103 can be volatile or nonvolatile memory. Memory 103 can also beremovable (e.g., portable) memory, or non-removable (e.g., internal)memory. For example, memory 103 can be random access memory (RAM) (e.g.,dynamic random access memory (DRAM) and/or phase change random accessmemory (PCRAM)), read-only memory (ROM) (e.g., electrically erasableprogrammable read-only memory (EEPROM) and/or compact-disc read-onlymemory (CD-ROM)), flash memory, a laser disc, a digital versatile disc(DVD) or other optical disk storage, and/or a magnetic medium such asmagnetic cassettes, tapes, or disks, among other types of memory.

Further, although memory 103 is illustrated as being located in DCS 102,embodiments of the present disclosure are not so limited. For example,memory 103 can also be located internal to another computing resource(e.g., enabling computer readable instructions to be downloaded over theInternet or another wired or wireless connection).

As shown in FIG. 1, DCS 102 can also include a user interface 106. Userinterface 106 can include, for example, a display (e.g., a screen). Thedisplay can be, for instance, a touch-screen (e.g., the display caninclude touch-screen capabilities).

User interface 106 (e.g., the display of user interface 106) can provide(e.g., display and/or present) information to a user of DCS 102. Forexample, user interface 106 can provide the user interfaces 210, 326,432, 534, and/or 636, described herein in connection with FIGS. 2-6 tothe user.

Additionally, DCS 102 can receive information from the user of DCS 102through an interaction with the user via user interface 106. Forexample, DCS 102 (e.g., the display of user interface 106) can receiveinput from the user via user interface 106. The user can enter the inputinto DCS 102 using, for instance, a mouse and/or keyboard associatedwith DCS 102, or by touching the display of user interface 106 inembodiments in which the display includes touch-screen capabilities(e.g., embodiments in which the display is a touch screen).

The DCS can receive an indication of a demand response event(illustrated in FIG. 1 as “demand response signal” and hereinafterreferred to as “event 106”). As previously discussed, an event caninclude a signal and/or a request to adjust (e.g., reduce) load. Anevent can be a signal in response to which a number of loads are shutdown or run at reduced capacity. In order to reduce loads, operations ofone or more devices can be adjusted. Such adjustment may be made inorder to meet a usage target (e.g., kilowatt hour target). In someembodiments, one or more devices can be deactivated (e.g., according toa schedule). In some embodiments, setpoints associated with one or moredevices can be modified.

In some embodiments, events can be sent (e.g., issued) from a utility.In some embodiments, events can be passed from a virtual top node (VTN)and/or aggregator. For example, a demand response signal 106 can bereceived from a demand response automation server. In some embodiments,events can be scheduled (e.g., manually scheduled) by facilitiesthemselves. Accordingly, an indication of an event can be received basedon a manually-scheduled demand response event 104.

The system 100 can include a plurality of loads (referred tocollectively as “loads 108”). For instance, the system 100 can include afirst load 108-1, a second load 108-2 (e.g., “Rooftop Unit”), a thirdnode 108-3 (e.g., “Third Party Device”), and a fourth load 108-4 (e.g.,“BACnet device”). Though four loads 108 are shown in FIG. 1, embodimentsof the present disclosure can include more or fewer loads. Additionally,the types of loads illustrated in FIG. 1 (e.g., “Rooftop Unit,” “ThirdParty Device,” “BACnet device” are used as example types; embodiments ofthe present disclosure are not limited to the types illustrated in FIG.1.

Each of the loads 108 can be in communication with the DCS 102 via ademand settings component. In some embodiments the demand settingscomponent(s) can receive command(s) to shed load from the DCS 102 andcan communicate status information back to the DCS 102. The DCS 102 canreceive events as described above and determine which loads are to bereduced and/or how the reduction is to take place. Such information canbe communicated to the demand settings component(s) via the shedcommand(s). For the Rooftop Unit load 108-2 and the BACnet device load108-4, the corresponding demand settings components can directmodifications to control settings in order to reduce load.

For the load 108-1, the shed command output of its demand settingscomponent can be linked to a Boolean output point (e.g., an arbitraryBoolean output point). For the Third Party Device load 108-3, awiresheet logic setup can be configured. For instance, the demandsettings component of the load 108-3 can be linked to an output point.In some embodiments, the wiresheet logic can use additional informationfrom the demand settings component of the load 108-3.

FIG. 2 illustrates a user interface 210 associated with monitoringdemand control in accordance with one or more embodiments of the presentdisclosure. The interface 210 can be displayed when the selectabledisplay element (e.g., tab) 212 is selected. As shown in FIG. 2, theinterface 210 can include a current status portion 216, a views portion,and a demand loads overview portion 218. Selection of another tab 214can cause the display of a demand control settings interface, discussedfurther below in connection with FIG. 6.

The current status portion 216 can include information associated with acurrent status of a demand response event associated with a facility.Such information, can include, for instance, current activity state(e.g., level) of the event, current operation mode, current power usage,current shed target, current baseline, etc. Such information may begeneral in nature in that it may not be particular to one or morespecific loads but may refer to the loads of the facility of a whole,for instance.

The views portion can include selectable display elements which, whenselected, can cause the display of other user interfaces. For instance,selection of the event level configuration button 220 can cause thedisplay of an interface 326 discussed below in connection with FIG. 3.Selection of the limiting schedule button 224 can cause the display ofan interface 432 discussed below in connection with FIG. 4. Selection ofthe limiting targets button 222 can cause the display of an interface534 discussed below in connection with FIG. 5.

The demand loads overview portion 218 can include information associatedwith the demand response event particular to each of a plurality ofloads associated with the facility. Such information can be specific toa current event. For instance, each row in the demand loads overviewportion 218 can correspond to an individual load in the facility havinga demand settings component (previously discussed). For each load,information can be provided in a dashboard-style at-a-glance format suchas, for example, demand control enabled/disabled status, shed groupidentification, command status, actual status, time in shed, time inrestore, zone temperature, active setpoint, load feedback, etc.Accordingly, a user can be made aware of the status of the event as itpertains to individual loads. At times in which an event is notoccurring, information may be blanked out, for instance.

Once loads are added, they can be configured by selecting the eventlevel configuration button 220. The interface can then provide a pop-upwindow with a table displaying settings for each operation mode andallow for configuration.

FIG. 3 illustrates an interface 326 associated with configuring loads inaccordance with one or more embodiments of the present disclosure. Theinterface 326 can be provided following the selection of the event levelconfiguration button 220 on the interface 210, previously described inconnection with FIG. 2. The interface 326 can receive configurationmodifications to each of the plurality of loads, for instance. Theconfiguration modifications can include modifications to a plurality ofsettings for each of a plurality of operation modes associated with theplurality of loads

The interface 326 can include a number of portions (e.g., tabs)corresponding to different operation modes. In some embodiments,operation modes can include “limiting,” “normal,” “moderate,” “high,”and/or “special,” though embodiments of the present disclosure are notso limited. Selection of a particular operation mode can allow forconfiguration of loads in that mode. For instance, as shown in FIG. 3,the “normal” event settings tab is selected.

Embodiments of the present disclosure can allow for the configurationsof multiple loads to be modified at once. For instance, the loads “RTUSales Front” and “RTU Sales Middle” are both selected in the exampleillustrated in FIG. 3. Also as shown, selection of the “shed strategy”configuration column can cause the display of a pop-up window 328allowing for the modification of that configuration for both loadssimultaneously.

Selection of the demand response schedule button of the interface 210,previously described in connection with FIG. 1, can cause the display ofan interface associated with scheduling manual demand response events.In some embodiments, normal, moderate, high, and/or special events canbe scheduled. In some embodiments, alternate and/or special events canbe set up in addition to scheduled (e.g., weekly) events.

FIG. 4 illustrates an interface 432 associated with scheduling limitingevents in accordance with one or more embodiments of the presentdisclosure. Selection of the limiting schedule button 224 (previouslydescribed in connection with FIG. 2) can cause the display of theinterface 432, for instance. A limiting event can be scheduled for aparticular period of time, at a particular time, on one or more days ofa week. The limiting event(s) can be “peak,” “off-peak,” or “alt-peak”events according to some embodiments. Such differentiation can allow forflexibility in a limiting strategy by accounting for time of varyingusage. For example, during the middle of a summer day, a peak limitingevent may be scheduled instead of an off-peak event to prevent thefacility from shedding a particular amount (e.g., too much for comfort).

In contrast with previous approaches, where users may be restricted to12 alternate schedules representing different months, embodiments hereincan allow for the creation and/or modification of customizableschedules. Each schedule can have its own set of peak values (e.g., 3peak values). Such embodiments can provide the ability for an enterpriseto batch push a limiting schedule to a number of different facilitieswhile allowing each facility to maintain its own peak values, which mayvary based on location, for instance.

FIG. 5 illustrates an interface 534 associated with modifying peaktargets in accordance with one or more embodiments of the presentdisclosure. Selection of the limiting targets button 222 from the userinterface 210, previously described in connection with FIG. 2, can causethe display of interface 534, for instance. In some embodiments, theinterface 534 can be a pop-up window that allows for the editing of peaktargets in bulk. The interface 534 can display the peak targets for aweekly schedule. The interface 534 can display the peak targets for eachspecial event. The interface 534 can display the peak targets for one ormore alternate schedules. Selection of one or more schedules (as shownin FIG. 5) can allow the modification of one or more aspects of the peaktarget(s).

FIG. 6 illustrates an interface 636 associated with modifying demandcontrol settings in accordance with one or more embodiments of thepresent disclosure. The settings modified using the interface 636 can bemodifications nonspecific to any one particular load, for instance(e.g., settings that relate to the ADR system as a whole). Selection ofthe tab 214, previously described in connection with FIG. 2 andillustrated as tab 614 in FIG. 6, can cause the display of the interface636, for instance.

The interface 636 can include a control settings portion 638, a recoveryportion 640, a stage start portion 642, a load rolling/staging portion644, a limits portion 646, a demand limiting portion 648, a demandresponse configuration portion 650, and a baseline portion 652, thoughembodiments of the present disclosure are not so limited.

The control settings portion 638 can be configured to allow for enablingand/or disabling demand limiting. The control settings portion 638 canbe configured to set a demand response type (e.g., none, manual, or ADRservice).

The recovery portion 640 can be configured to set a recovery time takenafter an event ends to gradually restore each of a plurality of loads,for instance. A baseline percentage can be set, which can specify astarting recovery target. A restore delay time can be set, which canspecify a time in between the restoration of loads.

The stage start portion 642 can include portion configured to modify astartup duration, which can indicate how long it may take for all loadsto be restored following a station startup. A restore per interval valuecan be set, which can designate how many loads are to be restored foreach interval.

The load rolling/staging portion 644 can allow settings for shed delayand/or restore delay. Such delays may refer to a respective amount ofdelay between shedding and restoring loads individually. Rotation delaycan allow the modification of an amount of time between in-grouprotation. Group shed delay can allow the modification of a delay betweenshedding full groups (e.g., an initial behavior of a staging strategyuntil a target is met). “Restore from” can allow the selection ofwhether loads restored during staging are to be restored in an orderthey were shed or in an order of the most recently shed load beingrestored first. Rotation interval can refer to a load rolling strategyand can allow the modification of an interval between switching whichgroup is shed.

The limits portion 646 can allow modification of shed and restorethresholds. The limits portion 646 can allow modification of anoverlimit alert amount. For example, an overlimit alert can trigger analarm if current demand surpasses a demand target for a particularperiod of time (e.g., a threshold-exceeding period of time).

The demand limiting portion 648 can allow modification of the shed delayfor limiting. The demand limiting portion 648 can allow modification ofthe restore delay for limiting.

The demand response configuration portion 650 can allow a selectionbetween a load rolling strategy and a load staging strategy. Demandlimiting may use a load staging strategy by default, for instance. If,for example, a facility is using a manual demand response mode, a manualtarget for each operation mode can be configured and/or modified.

The baseline portion 652 can allow modification of informationassociated with a baseline. For example, the baseline portion 652 canallow configuration of baseline binning.

Load staging, as referred to herein, is a strategy in which loads can bedivided into shed groups based on importance. Loads designated as morecritical loads may tend to be placed in higher-numbered shed groups.Less important loads may be placed in lower-numbered shed groups. Otherloads, such as lighting, for instance, may be placed in a continuousshed group. When an event begins, all continuous loads can be shed, insome embodiments. The first group can then be shed. If a group rotationdelay elapses and the current usage remains above a threshold (e.g., a“shed above” usage), a second group can be shed. This process cancontinue until the current usage falls below a “shed above” range or allgroups have been shed. If the current usage falls below a “restorebelow” range, a restore delay timer can be activated. Once the restoredelay timer elapses, a load can be restored and the timer can berestarted. If the current usage rises above the “shed above” rangeagain, one load can be shed at a time. If current usage remains within adeadband range, then a partially shed group can rotate which loads areshed.

Load rolling, as referred to herein, is a strategy in which loads can beplaced in different groups with no preference of importance. In someembodiments, load rolling allows a single group to be shed at a time,but rotates one whole group every time the rotation interval timerelapses. If the facility's demand remains above a restore target, therotation can continue spreading the effects of the demand curtailmentamong the configured shed groups by shedding another group and restoringthe first group, one group at a time. If the demand drops below therestore target and remains below the restore target for at least onerotation interval, the load rolling strategy can terminate the periodicgroup rotation and loads can begin to be restored. The load rollingstrategy can then return to group rotation if the demand rises above ashed target. If the demand remains between the shed target and therestore target, the current mode can be continued, either rotating theshed group or waiting for the demand to rise into the shed range.

In previous approaches, ADR may include a number of (e.g., 2) “shedregisters” with a fixed number of slots to which loads are attached.Such loads may have a single response (e.g., setpoint adjust or loadshed off) irrespective of what type of event was received. In contrast,embodiments of the present disclosure can utilize virtual shed groupswhich can be read at the time of an event. Each load can have adifferent shed group for each different operation mode, thereby allowinga greater deal of flexibility when configuring a strategy. When a demandresponse action is taken by the DCS (previously discussed in connectionwith FIG. 1), the DCS can query demand settings component(s) in thefacility to determine which loads can be acted upon based on their shedgroup for the current operation mode. Accordingly, each load can responddifferently depending on the type of event. For a normal event, forinstance, a load may undergo a setpoint adjustment of two degrees. For amoderate event, for instance, when demand reduction is more urgentlyneeded, the load could be shut off entirely. Similarly, a normal eventcan utilize a higher number of (e.g., four) shed groups for gradualshedding to meet its target, while a high event may use a lower numberof (e.g., 2) shed groups for a quicker response.

Embodiments of the present disclosure can allow for more logicalconfiguration than previous approaches. A multitude of aspects of ADRcontrol can be overseen and/or modified from one place (e.g., thecomputing device described above in connection with FIG. 1). Forinstance, the computing device can configure aspects of the facility asa whole (e.g., strategy, timers, etc.), and individual loads themselves(e.g., shed strategies, shed groups, etc.). Additionally, the computingdevice can configure devices and allow for a user to check on a devicethat may not be operating as expected.

Although specific embodiments have been illustrated and describedherein, those of ordinary skill in the art will appreciate that anyarrangement calculated to achieve the same techniques can be substitutedfor the specific embodiments shown. This disclosure is intended to coverany and all adaptations or variations of various embodiments of thedisclosure.

It is to be understood that the above description has been made in anillustrative fashion, and not a restrictive one. Combination of theabove embodiments, and other embodiments not specifically describedherein will be apparent to those of skill in the art upon reviewing theabove description.

The scope of the various embodiments of the disclosure includes anyother applications in which the above structures and methods are used.Therefore, the scope of various embodiments of the disclosure should bedetermined with reference to the appended claims, along with the fullrange of equivalents to which such claims are entitled.

In the foregoing Detailed Description, various features are groupedtogether in example embodiments illustrated in the figures for thepurpose of streamlining the disclosure. This method of disclosure is notto be interpreted as reflecting an intention that the embodiments of thedisclosure require more features than are expressly recited in eachclaim.

Rather, as the following claims reflect, inventive subject matter liesin less than all features of a single disclosed embodiment. Thus, thefollowing claims are hereby incorporated into the Detailed Description,with each claim standing on its own as a separate embodiment.

1. (canceled)
 2. A method for providing demand response, the methodcomprising: receiving an indication of a demand response event;customizing a demand response strategy for each of two or more loads ofa facility in response to the indication of the demand response event,wherein customizing the demand response strategy comprises: determininga first action to be executed by a first load of the two or more loadsof the facility, wherein the first action to be executed is determinedby an input from a user via a user interface, wherein the user interfaceincludes two or more selectable display tabs, and the input receivedfrom the user is received via one of the two or more selectable displaytabs; communicating the first action to a controller associated with thefirst load for execution; determining a second action to be executed bya second load of the two or more loads of the facility, wherein thesecond action to be executed is determined by a second input from theuser via one of the two or more selectable display tabs; andcommunicating the second action to a controller associated with thesecond load for execution; monitoring a status of the first action and astatus of the second action; and displaying the status of the firstaction and the status of the second action concurrently on one of thetwo or more selectable display tabs of the user interface.
 3. The methodof claim 2, wherein the indication is a demand response signal receivedfrom a demand response automation server.
 4. The method of claim 2,wherein the demand response event is a manually-scheduled demandresponse event.
 5. The method of claim 4, wherein the manually-scheduleddemand response event is one of: a normal event, a moderate event, ahigh event, and a special event.
 6. The method of claim 2, wherein thedemand response strategy is dependent on an intensity level of thedemand response event.
 7. The method of claim 2, wherein the demandresponse event is a limiting event.
 8. The method of claim 2, whereinone of the two or more selectable display tabs of the user interfaceincludes a demand loads overview portion.
 9. The method of claim 2,wherein the demand response event is a limiting event, and wherein themethod includes receiving a schedule associated with the limiting eventhaving a set of peak values.
 10. The method of claim 2, wherein thefirst action to be executed by the first load is determined based, atleast in part, on a user selection of a load staging strategy or a loadrolling strategy.
 11. A system for providing demand response,comprising: a processor; and a memory configured to store instructionswhich, when executed by the processor, cause the processor to: providean interface having two or more selectable display tabs, a first one ofthe two or more selectable display tabs responsive to a first input, to:monitor and display a current status of a demand response eventassociated with a facility; display first information associated withthe demand response event, wherein the first information specificallyrefers to each of a plurality of loads associated with the facility; andreceive a customized demand response strategy for each of the pluralityof loads, wherein the customized demand response strategy includesconcurrent modifications to each of a plurality of demand response eventoperation modes associated with the plurality of loads; and a second oneof the two or more selectable display tabs responsive to a second inputto: display second information associated with the demand responseevent, wherein the second information does not specifically refer toeach of the plurality of loads associated with the facility.
 12. Thesystem of claim 11, wherein the displayed current status of the demandresponse event includes an indication of a current activity level of thedemand response event.
 13. The system of claim 11, wherein the displayedcurrent status of the demand response event includes an indication of acurrent demand response event operation mode associated with theplurality of loads.
 14. The system of claim 11, wherein theconfiguration modifications include modifications to a plurality ofsettings for a manual demand response event.
 15. The system of claim 11,wherein customizing the customized demand response strategy is based onan intensity level of the demand response event.
 16. The system of claim11, wherein one of the two or more selectable display tabs of the userinterface includes a demand loads overview portion.
 17. A non-transitorycomputer readable medium having computer readable instructions storedthereon which, when executed by a processor, cause the processor to:receive an indication of a demand response event; customize, based on aninput received from a user interface, a demand response strategy foreach of two or more loads of a facility in response to the indication ofthe demand response event, wherein customizing the demand responsestrategy comprises: determining a first action to be executed by a firstload of the two or more loads of the facility, wherein the first actionto be executed is determined by an input from a user via the userinterface, wherein the user interface includes two or more selectabledisplay tabs, and the input received from the user is received via oneof the two or more selectable display tabs; communicating the firstaction to a controller associated with the first load for execution;determining a second action to be executed by a second load of the twoor more loads of the facility, wherein the second action to be executedis determined by a second input from the user via one of the two or moreselectable display tabs; and communicating the second action to acontroller associated with the second load for execution; monitor astatus of the first action and a status of the second action; anddisplay the status of the first action and the status of the secondaction concurrently on one of the two or more selectable display tabs ofthe user interface.
 18. The medium of claim 17, wherein the demandresponse strategy is dependent on an intensity level of the demandresponse event.
 19. The medium of claim 17, wherein one of the two ormore selectable display tabs of the user interface includes a demandloads overview portion.
 20. The medium of claim 17, wherein the firstaction to be executed by the first load is determined based, at least inpart, on a user selection of a load staging strategy or a load rollingstrategy.
 21. The medium of claim 17, wherein the indication is a demandresponse signal received from a demand response automation server.